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DETAILED ACTION 



Double Patenting 

1 . The nonstatutory double patenting rejection is based on a judicially created 
doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the 
unjustified or improper timewise extension of the "right to exclude" granted by a patent 
and to prevent possible harassment by multiple assignees. A nonstatutory 
obviousness-type double patenting rejection is appropriate where the conflicting claims 
are not identical, but at least one examined application claim is not patentably distinct 
from the reference claim(s) because the examined application claim is either anticipated 
by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 
F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 
USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 
1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 
F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 
USPQ 644 (CCPA 1969). 

A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) 
may be used to overcome an actual or provisional rejection based on a nonstatutory 
double patenting ground provided the conflicting application or patent either is shown to 
be commonly owned with this application, or claims an invention made as a result of 
activities undertaken within the scope of a joint research agreement. 

Effective January 1 , 1994, a registered attorney or agent of record may sign a 
terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 
37 CFR 3.73(b). 

2. Claims 1, 9, 12, and 21 are rejected on the ground of nonstatutory obviousness- 
type double patenting as being unpatentable over claims 1, 12, and 20 of U.S. Patent 
No. 7,093,120. Although the conflicting claims are not identical, they are not patentably 
distinct from each other because claims 1, 3, 9, 12, 15, and 21 of the application are 
directed towards providing SAN boot devices by storing a boot image of a boot device 
on a SAN and using the image to boot a SAN system, with the operation performing at 
SAN speeds. The patent US 7,093,120 claims 1,12, and 20 are directed toward 
booting machines from boot files from boot devices stored on SAN volumes. The patent 
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claims include the steps of sending and receiving queries to boot the system, yet these 
steps are an obvious variant and the omitting of these steps do not create a patentably 
distinct claim, since one of ordinary skill in the art at the time of invention would see the 
requirement of sending and receiving queries to undergo the process of booting a 
machine. In addition, the patent claims are silent in respect to operating at SAN 
speeds, yet the inclusion of the SAN connected to the machine in the claims implies 
SAN speeds. 



Claim Objections 

3. Claims 2, 6, 7, 12, 14, 16, and 17 objected to because of the following 
informalities: 

Regarding claim 2, the term "a boot device" in line 4 has already been defined 
and should be replaced with --the boot device- to improve claim clarity. 

Regarding claim 6, the terms "a boot device" in lines 3 and 6 and "boot device" in 
line 7 have already been defined and should be replaced with -the boot device- to 
improve claim clarity. 

Regarding claim 7, the term "a boot up" on lines 5-6 has already been defined 
and should be replaced with -the boot up- to improve claim clarity. 

Regarding claim 12, the period at the end of line 8 should be replaced with ~; 
and- to improve the clarity of the claim language. 

Regarding claim 14, the term "a the boot device" on line 8 is grammatically 
incorrect and should be replaced with -the boot device-. 
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Regarding claim 16, the terms "a boot device" in lines 3 and 8 and "boot device" 
in line 9 have already been defined and should be replaced with -the boot device- to 
improve claim clarity. 

Regarding claim 17, the term "a boot up" on lines 5-6 has already been defined 
and should be replaced with -the boot up- to improve claim clarity. 

Appropriate correction is required. 

Claim Rejections - 35 USC § 101 

4. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 

Claims 21-23 are rejected under 35 U.S.C. 101 because the claimed invention is 
directed to non-statutory subject matter. 

Regarding claims 21-23, the claims are directed towards a computer program 
product, which is computer code on a computer readable medium. A computer 
readable medium is defined in the specification in section 0060 to be carrier waves. 
Carrier waves and other electromagnetic phenomenon do not fall into a statutory 
category of invention such as a process, a manufacture, a method, or a composition of 
matter, and computer code simply "on" waves does not make them patentable subject 
matter. In addition, computer code on a medium, which does not execute is non- 
functional descriptive material. Computer code must be stored on storage mediums 
and be executed by a processor in order to be statutory subject matter. 
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Claim Rejections - 35 USC § 102 

5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

6. Claims 1-5, 9, 11-12, 15, and 20-21 are rejected under 35 U.S.C. 102(e) as 
being anticipated by Chang (US 2003/0126242). 

Regarding claim 1, Chang anticipates: 

In a storage area network (SAN) computer system having a volume group made 
up of one or more physical disks, a method for providing SAN boot devices 
(section 001 1 , lines 6-12, with the boot volume selected from multiple boot 
volumes, seen as a volume group made up of one or more physical disks and 
section 0020, lines 1-3, with a SAN system being used), said method comprising: 
storing a boot image from a boot device on at least one disk within said volume 
group (section 0022, lines 9-1 2m with the boot files being stores in the pooled 
storage); 

subsequently booting the SAN system from the boot image stored on the at least 
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one disk, wherein the SAN system's boot operation is completed from within said 
logical volume (section 0030, lines 12-15, with the client system accessing the 
boot image off the SAN storage, seen as booting the SAN system). 

Regarding claim 2, Chang anticipates: 

The method of Claim 1 , said storing step further comprising: 
copying boot install images from said first boot device to multiple disks within the 
volume group (section 0023, lines 3-12, with the boot images being stored on 
one or more pooled storage, seen as putting boot images on multiple disks within 
a volume group), whereby each disk of said multiple disks within said volume 
group may independently serve as a boot device for the SAN system and a boot 
process may be initiated from any one of the multiple disks in the volume group 
(section 0035, lines 7-18, with the client SAN system booting off of a unique 
image for that device found in one of the storage areas). 

Regarding claims 3 and 15, Chang anticipates: 

The method of Claim 1 or the SAN system of claim 12, wherein said storing step 
comprises: 

selecting the at least one physical disk on which to copy the boot install images 
(section 0023, lines 3-12, with the boot images being stored on one or more 
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pooled storage, seen as putting boot images on multiple disks within a volume 
group, or selecting the disks on with to copy boot images); 
selecting particular boot install images to copy to said at least one physical disk 
(section 0023, lines 3-12, with the boot images being stored on one or more 
pooled storage, and they are for different client systems, seen as selecting 
particular boot images), wherein less than all of said boot install images may be 
selected for copying (section 0023, lines 1-12, with the system having a base 
image alone for one embodiment and multiple different images for a different 
setup, seen as selecting less than all of the install boot images to copy). 

Regarding claim 4, Chang anticipates: 

The method of Claim 1 , wherein said storing step further comprises: building the 
boot image on a computer system associated with said SAN; and uploading the 
boot image to said logical volume (section 0022, lines 3-15, where the boot 
image is created on a computer and then uploaded in the pooled storage). 

Regarding claim 5, Chang anticipates: 

The method of Claim 1, wherein said subsequently booting step comprises 
switching a boot sequence from the first boot device that is external to said 
logical volume to the at least one disk (section 0029, lines 3-22, with the 
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computer first locally booting form a first boot device, seen as the power on or 
startup systems, then to retrieve the networked boot image, seen as switching to 
the logical volume of the SAN storage). 

Regarding claim 9, Chang anticipates: 

The method of Claim 1 , wherein said boot operation includes: 

reading of the boot image at SAN speed, wherein further no boot images are 

pulled from across the network; and 

installing images from the boot logical volume at said SAN speed (section 0037, 
lines 1-8, where a SAN system may be used with logical volumes and the files 
are sent across the SAN, seen as a SAN speed read). 

Regarding claims 11 and 20, Chang anticipates: 

The method of claim 1 or the SAN system of claim 12, wherein, when an 
administrator desires to install new optional programming parameters (OPPs), 
said method further comprises: importing the install volume group; mounting the 
file system hosted on said volume; installing the OPP images; updating a table of 
contents file for the file System; dismounting the file system; and exporting the 
volume group (section 0033, lines 2-1 1 , where an administrative agent may add 
changes to the client volume, seen as importing, mounting, and installing OPP 
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images, and then the new client volume is updated and then in section 0029, 
lines 14-22, the boot image retrieved is client specific, implying a table of 
contents has been updated to identify any client volume changed, and section ■ 
0022, lines 9-12 where the volume is created and stored, seen as dismounting 
and exporting the volume group). 

Regarding claim 12, Chang anticipates: 

A storage area network (SAN) data processing system, comprising: 
SAN fabric connection (section 0020, lines 1-3, with a SAN system being used); 
an input/output (I/O) device (section 0021, lines 5-7, with the I/O device); 
a logical volume comprised of one or more physical storage devices that are 
accessible on the SAN via the SAN fabric connection (section 0037, lines 1-10, 
with the SAN system having logical volumes, and it must have at least one 
physical disk); 

means for providing a copy of a boot device on at least one of the storage 
devices in said logical volume, wherein said copy enables a boot of said SAN 
system from within the logical volume at SAN speed (section 0022, lines 9-12 
with the boot files being stores in the pooled storage and section 0030, lines 12- 
15, with the client system accessing the boot image off the SAN storage, seen as 
booting the SAN system, and section 0037, lines 1-8, where a SAN system may 
be used with logical volumes and the files are sent across the SAN, seen as a 
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SAN speed read); and 

means for booting said SAN system by installing images from the boot logical 
volume at said SAN speed (section 0030, lines 12-15, with the client system 
accessing the boot image off the SAN storage, seen as booting the SAN system, 
and section 0037, lines 1-8, where a SAN system may be used with logical 
volumes and the files are sent across the SAN, seen as a SAN speed read). 

Regarding claim 21, Chang anticipates: 

A computer program product, comprising: 
a computer readable medium; and 

program code on said medium that enables a system administrator to access a 
boot device (section 0033, lines 2-5, with the administrative agent access the 
boot image for a client) and copy boot install images from the boot device to a 
physical disk on a SAN (section 0022, lines 9-12, where the boot devices are 
copied to pooled storage and section 0020, lines 1-9, where SAN storage is 
used) which a logical volume is provided (section 0037, lines 1-7, with SAN 
logical volumes), wherein said physical disk serves as a boot device for said 
logical volume during subsequent boot (section 0030, lines 12-15, with the boot 
image, seen as a boot device on a disk, being used to boot the client from the 
pooled storage, and section 0037, lines 1-7, with SAN logical volumes being 
implemented to store the boot devices). 
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Claim Rejections - 35 USC § 103 

7. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

8. Claims 13-14 and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Chang (US 2003/0126242) in view of Rietze et al. (US 6,904,482). 

Regarding claim 13, Chang teaches all of the limitations as described above 
except for having a unique ID for each storage device, and having a BIOS in 
each SAN system, with a mechanism for turning it on and off, wherein a boot is 
initiated by the BIOS from an image stored on the storage device. The general 
concept of having an ID for each storage device and then booting from a BIOS 
upon turn on is well known in the art as illustrated by Rietze et al. Rietze et al. 
teaches that upon turn on, a BIOS controls the system to look for a OS on the 
network (column 7, lines 39-48), and the network is a SAN (column 6, lines 31- 
33), and each OS has a corresponding ID (column 7, lines 3-5, with each OS 
being identified using the OS identifier, seen as an ID for a storage device). It 
would have been obvious to one of ordinary skill in the art at the time of invention 
to modify Chang with using Ids for storage devices, and booting from a BIOS to 
point to the network stored boot image upon power on as taught by Rietze et al. 
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in order to reduce the number of storage systems as to reduce the maintenance 
as noted in Rietze et al.'s disclosure in column 1, lines 12-20 and column 2, lines 
1-3. 

Regarding claim 14, Chang teaches all of the limitations as described above, 
including: 

Program code for copying boot install images from said first boot device to 
multiple disks within the volume group (section 0023, lines 3-12, with the boot 
images being stored on one or more pooled storage, seen as putting boot 
images on multiple disks within a volume group), whereby each disk of said 
multiple disks within said volume group may independently serve as a boot 
device for the SAN system and a boot process may be initiated from any one of 
the multiple disks in the volume group (section 0035, lines 7-18, with the client 
SAN system booting off of a unique image for that device found in one of the 
storage areas). 

Chang does not teach program code for updating a table that provides a list of all 
boot devices accessible to the SAN system, including each storage device to 
which the boot install image is copied. The general concept of using a table and 
updating it to list available boot devices and each storage device that the boot 
image is copied to is well known in the art as illustrated by Rietze et al. Rietze et 
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al. teaches that a list of OS identifiers can be used to retrieve a list of boot 
devices accessible to the SAN system, and it includes the location or address of 
the storage device as well (column 7, lines 3-17). The list will be updated with 
new OS entries (column 7, lines 25-26, with the storage hosting a plurality of 
OS's, seen as creating new entries upon each OS's installation). It would have 
been obvious to one of ordinary skill in the art at the time of invention to modify 
Chang with using Ids for storage devices, and table for listing the storage devices 
and OS identifiers as taught by Rietze et a I. in order to reduce the number of 
storage systems as to reduce the maintenance as noted in Rietze et al.'s 
disclosure in column 1, lines 12-20 and column 2, lines 1-3. 

Regarding claim 23, Chang teaches all of the limitations as described above 
including using logical volumes for booting (section 0037, lines 1-7, with SAN 
logical volumes being implemented to store the boot devices), however Chang 
does not teach using program code to select a default boot device and wherein a 
path to the default boot device is encoded in the BIOS path. The general 
concept of booting from a default boot device and having the path encoded in the 
BIOS is well known in the art as illustrated by Rietze et al. Rietze et al. teaches 
that a boot device is selected based on the server identifier (column 7, lines 3-17, 
with using a server identifier is seen as selecting a default boot device since it will 
automatically find the right OS to boot) and Rietze et al. also teaches the path to 
the default boot image is encoded in the BIOS (column 7, lines 40-48). It would 
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have been obvious to one of ordinary skill in the art at the time of invention to 
modify Chang with using default boot devices and encoding of the path into the 
BIOS as taught by Rietze et al. in order to reduce the number of storage systems 
as to reduce the maintenance as noted in Rietze et al.'s disclosure in column 1, 
lines 12-20 and column 2, lines 1-3. 

9. Claims 6-8, 10, 16-19, and 22 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Chang (US 2003/0126242) in view of Cromer et al. (US 5,860,001 ). 

Regarding claims 6 and 16, Chang discloses all of the limitations as described 
above, including the use of SAN based disks in logical volumes for storing boot 
images (section 0020, lines 1-3, and section 0037, lines 1-7, with SAN logical 
volumes being implemented to store the boot devices with a SAN system being 
used) and switching a boot sequence from the first boot device that is external to 
said logical volume to the at least one disk (section 0029, lines 3-22, with the 
computer first locally booting form a first boot device, seen as the power on or 
startup systems, then to retrieve the networked boot image, seen as switching to 
the logical volume of the SAN storage). Chang does not disclose booting up a 
SAN system in maintenance mode, and generating a prompt for a system 
administrator to select a boot device from among a displayed list of available 
boot devices, and then automatically encoding the identification and routing 
information of the selected boot device in the BIOS. The general concept of 



Application/Control Number: 10/687,240 Page 15 

Art Unit: 2145 

booting in maintenance mode, then selecting a boot device from a list, and then 
booting from the device using information in the BIOS is well known in the art as 
illustrated by Cromer et al. Cromer et al. teaches that a system can be booted in 
maintenance mode to allow the selection of boot devices from a boot device list 
(column 7, lines 56-60, and column 8, lines 15-24). This information is stored in 
the BIOS as identification and routing, since it identifies what device to use, and 
how to access that boot device, such as a network boot, and since the BIOS runs 
the POST, or "power on self test", the BIOS is responsible for booting operations 
upon startup (column 3, lines 11-15 and column 7, lines 48-55). It would have 
been obvious to one of ordinary skill in the art at the time of invention to modify 
Chang with using a maintenance mode to select a boot device and then storing 
that selection in the BIOS as taught by Cromer et al. in order to customize boot 
up procedures depending on how a computer was powered on as to increase 
automation as noted in Cromer et al.'s disclosure in column 2, lines 60-64. 

Regarding claims 7 and 17, Chang discloses all of the limitations as described 
above, including using a SAN (section 0020, lines 1-3, with a SAN system being 
used). Chang does not teach monitoring for an occurrence of a predefined 
condition and initiating said switching when one of a plurality of said predefined 
condition occurs; 

wherein said predefined conditions include: (1) receiving an error signal from the 
first boot device when a boot up is desired; (2) being unable to access said first 
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boot device when a boot up is desired; (3) encountering a failure on said SAN 
computer system that results in a shut down of said system; and (4) system 
administrative directive to re-boot system from a selected one of said at least one 
disk. 

The general concept of switching boot devices when one of a plurality of these 
conditions occurs is well known in the art as illustrated by Cromer et al. Cromer 
et al. teaches that a boot device switching from a local boot to a network boot 
occurs upon being unable to access the first boot device (column 10, lines 58-67 
and column 1 1 , lines 1 -5). It would have been obvious to one of ordinary skill in 
the art at the time of invention to modify Chang with monitoring for a predefined 
condition to enact switching of the boot devices as taught by Cromer et al. in 
order to customize boot up procedures depending on how a computer was 
powered on as to increase automation as noted in Cromer et al.'s disclosure in 
column 2, lines 60-64. 

Regarding claims 8 and 18, Chang discloses all of the limitations as described 
above, including the use of SAN based disks in logical volumes for storing boot 
images (section 0020, lines 1-3, and section 0037, lines 1-7, with SAN logical 
volumes being implemented to store the boot devices with a SAN system being 
used). Chang does not teach selecting a first boot disk, and then upon failure of 
the first boot disk, selecting a second boot disk according to a pre-established 



Application/Control Number: 10/687,240 Page 17 

Art Unit: 2145 

order. The general concept of switching boot disks upon failure of the first boot 
disks according to an order is well known in the art as illustrated by Cromer et al. 
Cromer et al. teaches boot disks can be tried in series upon failures according to 
an order (column 7, lines 48-55). It would have been obvious to one of ordinary 
skill in the art at the time of invention to modify Chang's SAN based boot disks 
with serially attempting to boot from devices according to an order as taught by 
Cromer et al. in order to customize boot up procedures depending on how a 
computer was powered on as to increase automation as noted in Cromer et al.'s 
disclosure in column 2, lines 60-64. 

Regarding claims 10 and 19, Chang discloses all of the limitations as described 
above including using logical volumes on a SAN boot volume (section 0020, lines 
1-3, and section 0037, lines 1-7, with SAN logical volumes being implemented to 
store the boot devices with a SAN system being used), pointing the system at the 
install volume group (section 0029, lines 14-22, with the response pointing the 
system at the right path to the install image); initiating an boot installation process 
to import the install volume group (section 0030, lines 12-15, with the system 
booting off of the found client specific image); and install the base operating 
system (BOS) image, which in turn installs the proper devices and optional OPP 
support desired (section 0022, lines 9-12, with the images being OS and 
application files, seen as BOS and optional OPP support). Chang does not teach 
performing this method upon an occurrence of a corrupted boot volume. The 
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general concept of switching boot disks upon failure of the first boot disks is well 
known in the art as illustrated by Cromer et al. Cromer et al. teaches boot disks 
can be tried in series upon failures according to an order (column 7, lines 48-55). 
It would have been obvious to one of ordinary skill in the art at the time of 
invention to modify Chang's SAN based boot disks with serially attempting to 
boot from devices as taught by Cromer et al. in order to customize boot up 
procedures depending on how a computer was powered on as to increase 
automation as noted in Cromer et al.'s disclosure in column 2, lines 60-64. 

Regarding claim 22, Chang discloses all of the limitations as described above, 
except program code for displaying a graphical user interface (GUI), wherein said 
GUI displays a list of available boot install devices and enables a system 
administrator to manually select which device among the list of available boot 
install devices to utilize as a boot install device, and wherein further said GUI 
enables a system administrator to set up a physical volume to receive a copy of 
said boot image. The general concept of displaying a GUI to allow a selection of 
boot devices among a list of available boot devices, and set up a volume to 
receive the copy of the boot image is well known in the art as illustrated by 
Cromer et al. Cromer et al. teaches a GUI can be accessed to change the order 
of boot devices, seen as setting a boot install device (column 8, lines 15-26 and 
38-41 ), and if the network is chosen as a boot device, then remote booting 
occurs, seen as setting up the physical volume on the computer to receive the 
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copy of the boot image (column 1 1 , lines 2-5). It would have been obvious to 
one of ordinary skill in the art at the time of invention to modify Chang with 
serially attempting to boot from devices according to an order created by a GUI 
as taught by Cromer et al. in order to customize boot up procedures depending 
on how a computer was powered on as to increase automation as noted in 
Cromer et al.'s disclosure in column 2, lines 60-64. 

Conclusion 

1 0. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

Heil (US 6,895,480) teaches sharing a boot volume among server blades on a 
SAN system. 

Cronk et al. (US 6,532,538) teaches running multiple operating systems at the 
same time using identification keys. 

Panas et al. (US 6,473,857) teaches loading boot images from a mass storage 
system. 

"Functionality and Performance Evaluation of File Systems for Storage Area 
Networks (SAN)" (Bancroft et al.) describes SAN systems and their solutions. 



Application/Control Number: 10/687,240 
Art Unit: 2145 



Page 20 



"Volume Management in SAN environment" (Kim et al.) teaches logical volume 
management for SAN systems. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Adam S. Weintrop whose telephone number is 571-270- 
1604. The examiner can normally be reached on Monday through Friday 7:30am- 
5:00pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Jason Cardone can be reached on 571-272-3933. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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